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(54) Method and apparatus for analyzing one or more firewalls 



(57) A method and apparatus are disclosed for an- 
alyzing the operation of one or more network gateways, 
such as firewalls or routers, that perform a packet filter- 
ing function In a network environment. Given a user que- 
ry, the disclosed firewall analysis tool simulates the be- 
havior of the various firewalls, taking into account the 
topology of the network environment, and determines 
which portions of the services or machines specified in 
the original query would manage to reach from the 
source to the destination. The relevant packet-filtering 
configuration files are collected and an intemal repre- 
sentation of the implied security policy is derived. A 
graph data structure is used to represent the network 



topology. A gateway-zone graph permits the firewall 
analysis tool to determine where given packets will trav- 
el in the network, and which gateways will be encoun- 
tered along those paths. In this manner, the firewall anal- 
ysis tool can evaluate a query object against each rule- 
base object, for each gateway node in the gateway-zone 
graph that is encountered along each path between the 
source and destination. A graphical user interface is pro- 
vided for receiving queries, such as whether one or 
more given services are permitted between one or more 
given machines, and providing results. A spoofing at- 
tack can be simulated by allowing the user to specify 
where packets are to be injected into the network, whtoh 
may not be the true location of the source host-group. 
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Description 
Field Of The Invention 

[00011 The present invention relates generally to firewalls, and more particularly, to a method and, apparatus for 
analyzing the security policy of a firewall. 

Background Of The Invention 

f00021 Network firewalls provide important safeguards for any network connected to the Internet. Firewalls are not 
simple applications that can be activated "out of the box." A firewall must be configured and managed to ^alize an 
important security policy for the particular needs of a given company or entity. It has been said that the most important 
factor affecting the security of a firewall is the firewall configuration. While firewalls have seen impressive technical 
advances there have been few. if any. advances in firewall configuration and management. 

f0003] A firewall is a network gateway that filters packets and separates a proprietary corporate networit. such as 
an Intranet from a public networi<, such as the Internet. Most of today's firewalls are configured by means of a rule- 
base or firewall configuration file. In the case of a firewall guarding a single, homogeneous Intranet, such as the local 
area network (LAN) of a small company, a single rule-base Instructs the firewall which Inbound sessions (packets) to 
permit to pass, and which should be bk)cked. Similarly, the rule-base specifies whteh outbound sessions (packets) are 
permitted. The firewall administrator needs to implement the high-level corporate security policy using this low-level 

romr^he firewall's configuration interface typteally allows the security administrator to define various host-groups 
(ranges of IP addresses) and service-groups (groups of protocols and con^esponding port-numbers at the hosts that 
form the cndpoints). A single rule typical^ includes a source, a destination, a service-group and an appropnate action. 
25 The source and destination are host-groups, and the action is generally either an indteation to "pass or drop the 
packets of the corresponding session. ^ ' ^. „ ^ . »u r..io in tho 

[00051 In many firewalls, the rule-base is order sensitive. In other words, the firewall checks if the first rule n the 
rule-base applies to a new session. If the first rule applies, the packets are either passed or dropped according to the 
action specified by the first rule. C3then«ise. the firewall checks if the second rule applies, and so forth until a rule 
applies. This scheme often leads to misconfiguratlon due to redundant rules in the rule-base, and the desired secunty 

polfcy is realized only after re-ordering some of the rules. 

100061 The problems of administering a firewall are even worse for a larger company, which may use more than a 
single firewall. Multiple firewalls divkle a company's Intranets into multiple zones, and the security policy 's typcally 
realized by multiple rule-bases, located on multiple gateways that connect the different zones to each other. Thus, the 
interplay between the various rule-bases must be carefulV examined so as not to introduce security holes. The com- 
plexity of designing and managing the rule-bases grows, as the Intranets get more complex. 
[00071 Today, even a moderately sized corporate intranet contains multiple firewalls and routers, which are aH used 
to enforce various aspects of the global corporate security poltoy. Configuring these devtees to work in unison is difficult, 
especially if the devices are made by different vendors. Even testing or reverse engineering an existing configuration 
40 for example, when a new security administrator takes over, is hard. Rrewall configuration files are written in low-leve^ 
fomialisms, whose readability is comparable to assembly code, and the global policy is spread over all the firewalls 

that are involved. ^ . . ^ ... ^„ 

[00081 Cun-ently. firewall administrators do not have an easy way to deteninine the secunty pemnissions that are 
applicable to various classes of machines or sen/ices in a corporate environment. Ttius. it can be difficult, it not impos- 

45 sible for the administrator to answer routine questions regarding the corporate security poltey. such as whether one 
or more given sewices are peimitted between one or more given machines. There are several reasons why evaluation 
of thecorporatesecurity policy can be diffk^ult. First, packets may havemultiple paths between a source and destinaUon, 
with each path crossing several filtering devices. To answer a query, the administrator would need to check the rules 
on all of these. In addition, typical vendor configuration tools deal with a single devfce at a time, which may lead to 

so Inconsistent gtobal behavior. If packet-filtering devices made by different vendors are involved, the situation quickly 
becomes much worse. Furthemiore. even understanding the polfcy on a single interface of a single packet-fiKenng 
devk» is problematic. As previously indicated, firewall configuration languages tend to be arcane, very tow level, sen- 
sitive to rule order, and highly vendor specifte. , « . tm ^ 
[00091 Currently, a number of vulnerability testing tools are commercially available. Forexample,SatanTM,descnbed, • 

55 for example, in M. Freiss. Protecting Networks with SATAN, O'Reilly & Associates, Inc. (1998), attempts to explort 
known flaws in wMely dephjyed protocols and operating systems, some of which can be blocked by appropnate firewall 
policies In this manner, Satan™ can be used to test the firewall poltoy. In addition, NetSonar 2.0^^. commercially 
available from Cisco Systems Inc. of San Jose. CA. connects to a corporate intranet and probes the network, thereby 
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testing the deployed routing and firewall policies. 

[0010] Cun-ently available vulnerability testing tools are active. In other words, they send and receive paclcets on the 
network. As such, they suffer from several limitations, which if overcome, could greatly expand the utility and effipiency 
of such vulnerability testing tools. For example, if the intranet is large, with many thousands of machines current 
vulnerability testing tools are either slow (if they test every single IP address against every possible port) or statistical 
(If they do random testing). Certainly, they cannot test every possible IP address on the Internet 
[0011J In addition, current vulnerability testing tools can only catch one type of firewall configuration error allowinq 
unauthonzed packets through. They do not catch the second type of en-or inadvertently blocking authorized packets 
This second type of error is typically detected by a "deploy and wait for complaints" strategy, whk^h is disruptive to the 
network users and may cut off critical business applications. 

[O012] Active testing is always after-the-fact. Detecting a problem after the new policy has been deployed however 
IS (a) dangerous (since the network is vulnerable until the problem is detected and a safe policy is deployed)' (b) costIV 
(since deploying a security policy in a large network is a time consuming and error prone job), and (c) disruptive to 
users. Furthermore, an active tool can only test from its physical location in the network topology. A problem that is 
specific to a path through the network that does not involvethe host on whteh the active tool is running will go undetected 
[00131 A need therefore exists for a firewall analysis tool that allows an administrator to discover and test a global 
firewall policy. A further need exists for a firewall analysis tool that uses a minimal description of the network topology 
and directly parses the various vendor-specific low-level configuration files. Yet another need exists for a firewall anal- 
ysis tool that interacts with the user through a query-and-answer session, which is conducted at an appropriate level 
of abstraction. • 

Summary Of The Invention 

[001 4] Generally, a method and apparatus are disclosed for analyzing the operation of one or more firewalls or other 
network gateways, such as routers, that perfonn a packet filtering function in a networi< environment. The security 
policy for a particular networit environment Is typteally implemented by defining a packet filtering configuration file (a 
rule-base) for each firewall. The packet filtering configuration file instructs a given firewall whether to pass or drop 
certain inbound and outbound packets. Given a user query, the disclosed firewail analysis tool simulates the behavior 
of the vanous firewalls, taking into account the topology of the networic environment, and detennines which portions 
of the sewices or machines specified in the original query would manage to reach from the source to the destination 
[00151 The disclosed firewall analysis tool collects and reads the relevant packet filtering configuration files and builds 
an internal representation of the implied security policy. In addition, the firewall analysis tool utilizes a graph data 
structure to represent the networi< topology. A gateway-zone graph is comprised of a number of nodes interconnected 
by edges. Each node corresponds to either a gateway (firewall or router) or a zone created by a gateway Generally 
the present invention assumes that a given packet can travel along any physical path, even if not allowed according 
to the route scheme. The gateway-zone graph contains a node for each devce containing a packet-filtering mie-base 
and for each zone defined by such devtees. The firewall analysis tool does not need to be aware of every router and 
switch in the networic. and is indifferient to the routing scheme that is used. 

[00161 The gateway-zone graph permits the firewall analysis tool to determine where given packets will travel in the 
networic, and whteh gateways will be encountered along those paths. In this manner, the firewall analysis tool can 
evaluate a query object against each rule-base object, for each gateway node in the gateway-zone graph that is en- 
countered along each path between the source and destination. 

[001 71 According to a further aspect of the inventfon. the firewall analysis tool provides a graphteal user interface for 
receiving and evaluating simple queries, such as whether one or more given sewices are pemiitted between one or 
more given machines. The present invention permits a userto aggregate queries where a given service may be a set 
of services (up to a wildcard "all possible services"), and given machines may be arbitrary sets of IP addresses (up to 
a wildcard "all possible addresses"). According to a further feature of the present invention, the firewaU analysis tool 
can simulate a spoofing attack by altering the source IP address. The firewall analysis tool altows the user to specify 
where the packets are to be injected into the networic, whteh may not be the tme location of the source host-group 
The firewall analysis tool can also take into account firewall rules that perfonn networtc-address-translation (NAT) 
[00181 A more complete understanding of the present inventk>n. as well as further features and advantages of the 
present invention, will be obtained by reference to the following detailed description and drawings. 

Brief Description Of The Drawings 

[0019] 

FIG. iillustrates a representative networic environment in accordance with the present invention: 
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FIG. 2 illustrates the components of the firewall analysis tool of RG. 1 ; 

FIG. 3 illustrates a gateway-zone graph of the network environment of FIG. 1 ; 

FIG. 4 is a flow chart describing an exemplary query engine algorithm perfomied by the firewall anahfsis tool of 
FIG. 2; and 

FIGS. 5 through 7 are views of an exemplary graphical user Interface used by the firewall analysis tool of FIG. 2 
to receive a user query and provides results. 

Detailed Description 

,he wtwo-k-s lM.9-«y and sKouM bo '^P'f "'J "^""^^T^^^ sdmlnlstrMlon 

T^^sziz - - - • 

configuration file 125, 155, discussed below, '^^^^l^^'t^. firewall-specific rule-bases. In the multiple fire- 

(0024] As shown in FIG. 1 . ^''^P^^f"' '"^g .55 builds an Internal representation of the Implied security policy 
relevant packet filtenng configuration files 125. 155. and ^l^Jl"^^^.^ ^vides a graphical user interface 

machlr^es. A usercan aggregate queries wh^e a g.en^ 
sen,«es-). and given mach^^ rn^be^^^^^^^ 

tool 200 can also take Into account firewall rules that perfomi network-address-translation (NAT). 
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Firewall Terminology and Modeling Concepts 

[0026] Typically, a firewall configuration tool allows the security administrator to define various host-groups (collec- 
tions of IP addresses) and service-groups (groups of protocols and corresponding port-nunnbers at the hosts which 
fonm the endpoints). A single rule typically includes a source, a destination, a service-group, and an appropriate action: 
The source and destination are host-groups, and the action is typically to either "pass" or "drop" the packets of the 
corresponding session. In addition, the action may specify the writing of a log record or the performance of a networic- 
address-translation (NAT), 

[0027] As previously indicated, the rule-base is often order-sensitive. Generally, the firewall checks If the first rule in 
the rule-base applies to a new session. If so, the packets are either dropped or permitted to pass according to the 
action of the first rule. Othenvise, the firewall checks If the second rule applies, and so forth. 

[0028] As used herein, gateways are the packet filtering machines and can be either firewalls or routers. Normally, 
a gateway is multi-homed, since a gateway has at least two Internet connections. Typfcally. a gateway has multiple 
network connections. Each connection goes through an interface, which has Its own unique IP address. It is assumed 
that each interface has a packet filtering configuration file 125, 155 associated with it. The gateways partition the IP 
address space into disjoint zones, as shown in FIG. 1 . Precisely, a zone, z, is a maximal set of IP addresses such that 
packets sent between any two addresses in z do not pass through any filtering gateway. Most zones correspond to a 
corporation's subnet(s), usually with one big 'Internet" zone 110 conresponding to the portion of the IP address space 
that is riot used by the corporation. 
20 [0029] A service is the combination of a protocol-base, such as top or udp, and the port numbers on both the source 
and destination sides. For example, the servtee telnet is defined as tcp with destination port 23 and any source port. 
A service-group is simply a set of servces. 



10 



15 



25 



FIREWALL ANALYSIS TOOL 

[0030] As shown in FIG. 2, the firewall analysis tool 200 requires an Instantiated model of the networi< topology, as 
described in a user-written topology definition file 21 0, discussed further below in the section entitled "Topology File." 
As shown in FIG. 2, the topology definition file 21 0 is written using a subset of the model definition language (MDL), 
discussed below in a section entitled "Model Definition Language (MDL)." 
30 [0031] As shown in FIG. 2, the query engine 240 of the firewall analysis tool 200 uses a combination of a graph data 
structure discussed below in conjunction with FIG. 3 and a rule-base simulator contained in a query algorithm 400. 
discussed below in conjunction with FIG. 4. As shown in FIG. 2. the query engine 240 takes as input a query from a 
user 220 consisting of a source and destination (both of which are host-groups) and a service group. 
[0032] According to one feature of the present Invention, the firewall analysis tool 200 does not need to be aware of 
every router and switch in the network, and Is indifferent to the routing scheme that is used. Generally, the present 
invention assumes that a given packet can travel along any physical path, even if not allowed according to the route 
scheme. The present invention considers those devices that have packet-filtering rule-bases installed on them, and 
the zones these devces define. At this level of granularity, the topology Is quite stable. Thus, the topology file 21 0 only 
needs to be modified If firewalls 120. 150 are added or replaced In the networi( 100. 

[0033] As part of the topology definition file 210, the user 220 specifies the names of the packet filtering configuration 
files 125, 155 (hereinafter, collectively referred to as firewall configuration files 230) that contain the mie-bases for all 
of the gateway interfaces 120, 150 in the networic environment 100. After reading the topology definition fOe 210. the 
firewall analysis tool 200 parses each of these configuration files 230 in turn (using a separate '^ront-end" module for 
each supported firewall variation), and populates Its internal rule-base data structures for each device. It is again noted 
that these firewall configuration files 230 are vendor-specific, and are created by whatever tools are used to configure 
the devices in questton. 

[0034] The user fonms a query by choosing each element of the query triple (servfce. source, destination), for ex- 
ample, from a drop-down menu offering the choice of all the host-groups or service-groups that were defined in the 
configuration files. 
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Topology Modeling 

[0035] The networic topology is modeled by partitioning the networic 100 into zones 130, 140. 160, which are con- 
nected through gateways. A gateway 120, 150 has an interface for each adjacent zone 130. 1 40, 1 60. Each Interface 
either has its own IP address (and is conskJered a host for some purposes), or is declared to be invisible (for example, 
using an INVIS keyword) if the firewall 120. 150 operates as a bridge. Packets leaving and entering a zone 130, 140. 
1 60 can be filtered by the gateway 1 20, 1 50 on the corresponding interface. Packets sent and received within the same 
zone 130, 140, 160 cannot be filtered by a gateway 120. 150, simply because the packets do not pass through any 
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Topology File 

further below. First, the host-groups are defined. 

HOST_GROUPS { 

,5 # the zones 

Z_dinz =[111.222.1.0/24] 
Z_corp =[111.222.2.0/24] 
Z.admin =[111 .222.3.0/24] 
Z.intemet- [0.0.0.0 -111.221.255.255. 

1 1 1 .222. 100.0 - 255.255.255.255] 
# the (visible) gateway interfaces 
^ I_dmz_in =[111.222.1.1] 

I_admin =[111.222.3.1] 

35 } 

I0037I It : r,oted that an IP address range can be specified in different ways. The slash notation defines a range by 
indicating how many of the most significant bits are fixed. 
40 [00381 Next, the interfaces are defined. 

INTERFACES { 

I_intemet_dinz = { INVIS. NO_<^ } 
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I 



drrxT. in 



= { file="-/fw/analy2er/data/dniz_in" } 



I^dmz^corp = { INVIS, NO^GEN } 



I_corp_in 



= {INVIS, 



fiIe='Wf\v/analyzer/data/corp_in" } 



I admin 



= { file="-/fw/analyzer/data/admin" } 



[0039] Interfaces with the NO_GEN attribute do not perform any filtering. Interfaces with the INVIS attribute do not 
have an IP address since they belong to a firewall that works as a bridge. 
[0040] Finally, the gateways and zones are defined. 



GATEWAYS { 

dmz _gw - {I_intemet_dinz, I_draz_in} : LMF 
corp .^gw = {I_dinz_cofp, I^corpjn, I^admin} : LMF 

) 

ZONES { 

Z^internet = { I_inteni^_dniz } 
Zjknz = { I_dm2_in, I_dmz_corp } 
Z_corp = { I_corp ja ) 
Z_adinin = { I^admin ) 



[0041 ] In the model used by the present inventfon, all the objects (hosts, host-groups, service-groups) generally have 
names. This provides a high level of abstraction when interacting with the user. Meaningful names are more expressive 
than raw IP addresses and port numbers. To the extent possible, the firewall analysis tool 200 obtains these names 
from the vendor-specific configuration files. However, since each device and Interface is assumed to have been con- 
figured independently, there may be name conflicts. For example, the administrator may have defined the name http 
to signify top on port 80 on one gateway, while on another gateway the administrator may use the same name to mean 
top on ports 80, 8000. and 8080. To support this level of naming, the firewall analysis tool 200 maintains a separate 
symbol table context per interface (i.e., per rule-base). If the same name appears in different contexts with different 
meanings, the firewall analysis tool 200 can optionally show all the variants In its drop-down menus, prefixed with the 
interface name. Otherwise, if all the variants are identical, the name will appear only once with no prefix. 



> 



Naming 



7 



EP. 



.in9l51A2_L> 



EP1 119 151 A2 



Rule-Bases 

[00421 The implicit security policy in place within the corporate network environment 1 00 is derived frorr^ the vendor 
specific packet filtering configuration files 126. 155. The firewall analysis tool 200 transforms each of these ^^^^^^^^ 
filtering configuration files 125. 155. associated with an Interface. Into a table of logical rules containing the following 
record structure (simplified for ease of explanation): 

struct rule { 

struct hostgrp *source; 
struct hostgip *dest; 
struct servicegrp * service jgrp; 

direction_ty direction; 

20 action_ty action; 

); 
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[00431 The actual semantics differ among different vendors. In the illustrative embodiment, the following exemplary 
semantics are utilized. When packets are filtered, the rules in the list are examined in their order until a nriatch occurs. 
The source, destination and service^grp fields are compared to the corresponding fields in the packet The direction 
specifies whether the rule applies to packets entering (IN) or leaving (OUT) the gateway 1 20. 1 50 on which this interface 
sits (i e the rules are gateway^entrlc). The wildcard direction (BOTH) indicates that the rule applies to both directions. 
If a match occurs, the corresponding action (DROP or PASS) is perfomied. The internal mle-base table also supports 
rules that perform NAT, and hence, the rule structure has some additional fields. 



Queries 



r00441 A central object in the firewall analysis tool 200 is a query. A query is a triple, consisting of a source host- 
group a destination host-group, and a service group. The semantics of such a query are "which IP addresses within 
the source host-group can send services from the service-group to which IP addresses In the destination host-group? 
" The query is described by the following data structure: 

Struct query { 

struct hostgrp *src; 
struct hostgrp *dst; 
struct servicegrp ♦service; 

}; 

[00451 it is again noted that host-groups and service-groups may be wildcards, i.e., any element of the query triple 
can be the wildcard, meaning "any." So the question "which machines can use the compan/s web-servers?" can 
be expressed by the query triple having the form (\ web.servers, http.sennces), assuming that the host-group 
web_sen/ers and the service-group http.services are defined. *»u 
[00461 Typically, not all the paclcets described by a query can reach the destination. Through the operations of the 
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various mfe-bases 125, 155, some packets may be dropped. Therefore, the firewall analysts tool 200 will answer such 
a query with a refined list of ^'sub-queries", i.e. . a list of query triples where each element is a subset of the corresponding 
element In the query triple. 

[0047] The semantics of the answer are that for each subset triple, the corresponding source host-group can indeed 
5 send the service to the destination host-group. 

Gateway-Zone Graph 

[0048] The firewall analysis tool 200 utilizes a graph data structure, to represent the network topology. FIG. 3 illus- 
10 trates a gateway-zone graph 300 for the network environment of FIG. 1 . The gateway-zone graph 300 is comprised 
of a number of nodes 31 1-316 interconnected by edges 321 -325. For a detailed discussion of the generation of gateway- 
zone graphs 300 in accordance with graph -theoretical principles, see, for example. T H. Connen et al., Introduction 
to Algorithms, 463-630 (MIT Press, 1989), incorporated by reference herein. The exemplary gateway-zone graph 300 
shown in FIG. 3 utilizes the following standard notation. The triangle symbol "A" indicates a gateway 120. 150 in the 
15 network 100, and the rectangle symbol "CJ indicates a zone 110, 130, 140 160 in the network 100. There is an edge 
321-325 between two nodes 311-316 if there is a physical connection between them. Generally, the gateway-zone 
graph 300 permits the firewall analysis tool 200 to determine where given packets will travel In the networt< 100, and 
which gateways 120, 150 will be encountered along those paths. 

[0049] For this purpose, Ihe internal model contains the following auxiliary graph. As used herein, the gateway-zone 
20 graph 300 is defined as a bi-partite graph H=((G <^ Z), I) whose vertrces consist of the set of gateways G and the set 
of zones Z. The set of interfaces I forms the edges: H contains an edge i=(g.z) connecting a gateway g £ G to a zone 
z E Z, if and only if g has an interface i whose adjacent-zone is z. 

[0050] The vertices of the gateway-zone graph 300 are implemented using the following structure: 
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Struct node { 

union { 



struct zone *2i 
stfuct gateway *gw; 

} 2g; 

Struct hostgrp '^hg; 
4o nodejty type; 

struct query *q; 

}' 

[0051] There is a node for each gateway and zone. The type field indicates whether a gateway or zone is represented 
by a given node. The hg field keeps the IP range contained in the node. For zone nodes, hg is the host-group of the 
zone minus the IP addresses of the interfaces adjacent to this zone. For gateway nodes, hg is the set of IP addresses 
^ of the interfaces attached to the gateway. The q field in the node structure is used forprocessing the query, as discussed 
below. 

Query Engine Algorithm 

ss [0052] The query engine of the firewall analysis tool 200 uses a combination of the graph data structure discussed 
above in conjunction with FIG. 3 and a rule-base simulator contained in a query algorithm 400, discussed below in 
corijunction with FIG. 4. As shown in FIG. 2, the query engine 240 takes as input a query from a user 220 consisting 
of a source and destination (both of which are host-groups) and a service group. It then simulates the behavior of all 
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the packets described by the query as they traverse the network. ... „ , .i. 

r00531 FIG 4 is a flow chart describing an exemplary query engine algorithm 400 perfoimed by the firewall analysis 
tool of FIG 2 As shown in FIG. 4, a user query is received during step 410 and the query is initially attached to t..e 
node in the gateway-zone graph which contains the source host-group during step 420. If the source host-group is not 

5 contained in a single zone, for example, when the wildcard, *. is used, the source host-group is broken up into disjoint 
host-groups during step 420, each of which is contained in a zone. A separate graph search is then performed dunng 
step 430 for each source host-group. Generally, the graph search evaluates the query object against each rule-base 
object discussed above, for each gateway node in the gateway-zone graph 300 that is encountered in the graph search. 
[00541 Then, the algorithm attempts to propagate the query over all the edges that connect the current node dunng 

10 step 440 The algorithm continues in the same nr«nner, propagating the query further until it searches the entire graph. 
All triples satisfying the query are identified during step 450 before program control terminates dunng step 460^ 
[00551 The basic step of the algorithm 400 is propagating a query over an edge in the gateway-zone graph 300. 
which represents a firewaH interface. This models the effect of the rule-base that is attached to the interface on the 
packets described by the query. Typically, only portions of the query can cross any given edge, since some of the 

15 packets would be dropped by the interface. Therefore, after crossing an edge, the query may need to be broken up 
into a set of more refined queries, that represent only those packets that would have been allowed through. For instance, 
the original query may have been (corporate_net. intemet. '). but the rule-base only allows outgoing http and smtp 
services so the set of queries that reaches the other side of the edge is now {corporate_net. intemet. tcp). 

(corporate_net, intemet, smtp). . • j . ■■ • 

20 [00561 It is noted that some nodes may be visited more than once, while other nodes will not be visited at all. since 
the algorithm 4O0 backtracks over all possible paths the query can take through the networi« 100, and continues as 
long as some portion of the query remains un-dropped. If the query can reach a node v (whether a zone or a gateway) 
via different paths, the new queiy that is attached to v is the union of the query results reaching von each of the possible 
paths. In one variation, the search can be optimized to not perfonn a traversal if it is clear that no new packets will be 
25 allowed through that have not been already by other paths. 

[00571 The final stage in processing a query is to collect the results during step 450. This simply involves looking at 
the node or nodes that contain the destination host-group and picking out those queries that have reached their correct 

destination. ^ . . 

[0058] In the worst case, the complexity of the algorithm 400 is exponential in the size of the gateway-zone graph 
30 300 However this worst case can only occur in very dense graphs. Typical gateway-zone graphs 300 are very sparse, 
since firewalls 120, 150 are nonnally placed at strategic choke points in the network, and the most common case 
gateway-zone graph topology Is a tree. On a tree topology, the algorithm is essentially a depth-first-search, i.e.. it is 
linear in the size of the graph. Furthermore, since only zones that are separated by firewalls are modeled, the gateway- 
zone graphs tend to be quite small. 

Spoofing 

[0059] A small extension to the basic algorithm 400 aHows testing for spoofing attacks. In addition to the source, 
destination and service parameters that define a query, an optional fourth parameter is added which specifies the true 
source from which the packets originate. When this fourth parameter is defined, the original source host-group is then 
understood to be the fake source address in the packet. The query can then be processed in the manner descnbed 
above, except that instead of starting from the nodes that contain the fake source host-group, the algorithm starts at 
those nodes that contain the true source. 

45 Example 

[0060] Consider the query: "What servfces are allowed between the corporate zone and the DMZ?" The results, 
shown in FIG. 5. reflect that the firewall configuration was done correctly in this regard. The services are available to 
alt the hosts in the corporate zone, but only control can open any tcp connection to the servers. In addition, note that 
so only the names of the host and service groups are displayed, but more detail (like actual IP address and port numbers) 
are available by expanding an entry (optionally via a mouse-cltok). 

[0061] In another example. consWer the query: "How much access does the Intemet 1 1 0 have to the internal network 
130 140 150'>" The results are shown in FIG. 6. The first five lines of the results show that any host on the Intemet 
lio'has some restricted access to the servers on the DMZ 130. Furthemiore, from the point of view of the firewall 
55 analysis tool 200. any host in the Intemet zone 1 1 0 can speak to any other host in that zone 1 1 0. which explains the 
third line The last line, however, indicates a weakness in the implementation of the security policy. This line indicates 
that any host on the Internet 110 can potentially open any servtee with the inner interface of the external gateway. 
Examination of the topology file will reveal the problem: The outer interface, UntemeLdrnz. does not perfonn any 
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filtering, and once packets have entered the gateway through it. they can speak to the other Interface without any 
filtenng. A more prudent approach, that solves this vulnerability. Is to attach the rulerbase to the outer interface rather 
than to the internal one. 

[0062J Another example illustrates how to check for spoofing. The most sensitive host is probably the firewall ad- 
5 ministrator 1 40, so no Internet host should be able to reach it. even with spoofing. To do this, the real source is set to 
be the Internet zone 110, and the given source (the spoofed address) is arbitrary. The results are shown In FIG 7 The 
leak that they indicate, is actually a result of the same problem seen in the previous query. An Internet host can create 
a message with the source address of the Ldmzjn interface. No filtering Is done on the outer interface and once 
inside, the packet is considered as if It originated from the Ldmzjn interface itself and. will be let through because it 
10 matches one of the rules. . 

[00631 >n a further extension of the query-answer mechanism of the present invention, additional infomiation about 
a query IS provided. For example, the query results can Indicate which rule in which Interface is responsible for passing 
or dropping a particular packet. Such inf omriatlon can displayed graphically to show the path packets take from source 
to destination. 

[0064] Another extension is to enhance the firewall analysis tool 200 to enable topology Independent queries via e 
g.. defining zones as being -internal- or -external." If the firewall analysis tool 200 can read in queries from a file, the 
user would then be in a position to use expert-generated queries to test the network for some bask: insecurities The 
expert quenes might cover well-known insecure ports or services and test accessibility of such ports from the external 
zones. As new vulnerabilities become known, organizations such as CEFTT could make updated query files available 
on their web-site for downloading. 



IS 



20 



25 



Model Definition Language (MDL) 

[0065] As described in EP-A-1 024 627 a model definition language (MDL) is used to instantiate the security poltey 
and to map the policy onto the topology. A parser translates an MDL program into an instance of the entity-relationship 
model. The model Is expressed by a corresponding data structure. 

MDL for Security Policy Description 

30 [0066] A servfce is defined by means of a statement in the form: 
<service-name> = 

<protocol-base> [<dest-port-no-range>, <src-port-no-range>]. 
[0067] For example, the following code fragment defines the widely used services smtp. ssh, ping, https and aserv»e 
denoting all tcp-based packets: 



35 



45 



so 



SERVICES { 

40 sn«P = TCP [25 J 

ssh = TCP [22] 
ping = ICMP [8,0] 
https = TCP [443] 
all_tcp = TCP [♦] 

} 

[00681 Services can be grouped into a servk>e-group. ServiceGrp. by a statement of the following fomi: 

<srv-grp-name> = {<sen/ice-nanne1>, <service-name2> ...} 
[0069] The following code fragment defines the two service-groups, admln-to-gtwy and gtwy-to-admin: 
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SERVICE^GROUPS { 

admin-to-giwy = {ssh, ping) 

5 

gtwy-to-admin = {ssh, https} 

100701 A role is defined by a statement of the following form, where the arrow defines the direction attribute in an 
,0 Es wa" the role-grp-name points to peers, and the sn,-grp-nan.e points to a sen,K:e-group: 
<role-name> arrow <role(-grp)-name> : <srv-grp-name> 

IS tinued in the next code fragment: 

ROLE_pEFINITIONS .{ 

mail_server * : smtp 
intemal_mail_sen^er <r^ inail_servcr : smtp 

^5 gateway Jn fw_admin : admin_to_gtwy 

gateway_out ->fw_admin : gtwy_to_adinin 

30 intranet jmachinc -> all_tcp : * 

} 



as 



[0072] Roles are grouped into open (by default) role-groups 325 by the following statement: 
<role-grp-hame> = { <role-namel>, <role-name2> ...} 
Roles are grouped into closed role-groups by the following statement: 

role-group. 

45 ROLE_.GROUPS { 

gateway = «gateway Jti, gateway_oui» # a closed group 
K/fni fnr Topolno y DescHp Hon and Policy Mappint^ 
Hosts and host-groups are defined by the following statements: 
<host-name> ^ [ <1P-Addr>] : <role-grp-namc> 
<host-grp-name> = [ <IP-Range>] : <role-grp-name> 



so 
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[0074] The following code fragment defines the hosts, dirty (presumably outside the. intranet) and dusty, assigning 
them roles of external and internal mail servers, respectively: 

* HOST{ 

dirty = [ 111.222.100.6] : mail_server 
10 dusty = ( 111.222.1.3] : mternal_inaa_server 

} 

IS Gateways are defined by the following statement: 

<gateway-name> = { <host-namel > <host-naine2> . . . } 

20 

[0075] The following code fragment defines payroll_gwJnterface1/2 as hosts and specifies their IP-addresses, and 
then defines the gateway payrolLgw as having payroll_gwJnterface1/2 as its two interfaces. The code fragment also 
assigns the role-group, gateway, to the interfaces. 

HOST { 

payroll,_gw_interfacel = [111.222.26.226 ) : gateway 
payroll_j;w_mterface2 [111.222.24.210 ] . gateway 

} 

GATEWAYS { 

payroil_gw - { payroll _gwjnterfacel, payroll_gwJnierface2} 

} 

Zones are defined by means of the following statement: 
<zone-name> : { <gtwy-interface-namcl>, <gtwy-interface-name2> ... } 

[0076] The following code fragment first defines the zones payrolLzone and corp_zone (parts of the intranet 
so manhattan_office) as host-groups, specifies their IP-ranges andthen defines parts of the network topology by specifying 
the payrolLzone to be connected to the payrolljw by means of the payroll_gw_interfacel, and the second interface 
of the payroll_gw to be connected to the corp_zone. 

55 
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HOST-GROUPS { 

manhattaii_office = [in.222.0.0.111.222.255.2551 : intranet.machine 
payroU_zone » [111.222.26.0-111.222.26.255] : payroll.machine 

corp.zone =[111.222.24.0.111.222.24.255]: 

non_payroll_inachine 

} 

ZONES { 

payroU_zone = {payroU_gw.interfecel ) 

coip_zone = { payroll_gw_mterface2, ... } 

) 

departing from the scope of the invention. 
Claims 

the steps of : 

of said addresses created by said at least one gateway; 

receiving a query inquiring whether one or more gVer, services are permitted between at least one source 
address and at least one destination address; and 

2. The method of claim 1 . wherein said mies are expressed as rule-base objects 

3. The method of claim 1 . wherein said gateway-zone graph is derived from a network topology file. 

4. The method of claim 1 . wherein said query includes a wildcard for at leas, one of said sen^ice. source address or ■ 
destination address. 

5 The method of claim 1 , further comprising the step of detem^ining a portion of said one o^'"^^* ^^'^'^^ 
JUS ^e pLitted between at least one source address and at least one destnat,on address. 
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6. The method of claim 1, further comprising the step of transfomning said packet filtering configuration files into a 
table of logical rules that are processed during said evaluating step. 

7. The method of claim 1 , wherein said query consists of a source host-group, a destination host-group, and a service 
5 host-group. 

8. The method of claim 1, wherein said query specifies a location where packets are to be Inserted Into the networic 
that is different from a source address. 

10 9. A method of modeling a network having a plurality of gateway devices, comprising the steps of: 

identifying each gateway device In said network having a packet-filtering rule-base and each zone in said 
network defined by said gateway devices; and 

15 generating a gateway-zone graph that models said network, said gateway-zone graph having a gateway node 

corresponding to each of said gateway devices and a zone node corresponding to each of said zones. 

10. The method of claim 9. wherein said gateway-zone graph Is derived from a network topology file. 

20 11. The method of claim 9, further comprising the step of transforming said packet-filtering rule-base Into a table of 
logical rules. 

12. An apparatus for analyzing at least one gateway in a network, sard at least one gateway having a packet filtering 
configuration file including a plurality of packet filtering rules, said network having a plurality of addresses, said 

25 tool comprising: 

a user interface for receiving a query inquiring whether one or more given services are permitted between at 
least one source address and at least one destination address, wherein each of said source addresses and 
said destination addresses correspond to one of said zones; and 

30 

a user interface for indicating a portion of said one or more given services that are penmitted between a portion 
of said at least one source address and a portion of said at least one destination address, said portions obtained 
by analyzing a gateway-zone graph that models said network with at least one gateway node corresponding 
to said at least one gateway and at least two zone nodes, wherein each of said zone nodes correspond to a 
35 partitioned collection of said addresses created by said at least one gateway. 

13. The method of claim 12, wherein said rules are expressed as rule-base objects 

14. The method of claim 12, wherein said gateway-zone graph is derived from a network topology file. 

40 

15. The method of claim 12, wherelri said query includes a wildcard for at least one of said sen/ice, source address 
or destination address. 

16. The method of claim 12, wherein said packet filtering configuration files are expressed as a set of logk:al rules. 

45 

17. The method of claim 12, wherein said query consists of a source host-group, a destination host-group, and a 

servrce host-group. 

18. The method of claim 12, wherein said user interface allows a user to specify a location where packets are to be 
so inserted into the network that is different from a source address. 

19. An apparatus for analyzing at least one gateway in a network, said at least one gateway having a packet filtering 
configuration file including a plurality of rules, said network having a plurality of addresses, said tool comprising: 

55 a memory for storing computer readable code; and 

a processor operatively coupled to said memory, said processor configured to: 
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generate a gateway-zone graph that models said network, said gateway-;?one graph having at least one 
gateway node corresponding to said at least one gateway and at least two zone nodes, wherein said at 
least one gateway is a packet filtering machine and each of said zone nodes correspond to a partitioned 
collection of said addresses created by said at least one gateway; 

5 

receive a query inquiring whether one or more given services are pemnitted between at least one source 
address and at least one destination address; and 

evaluate said query against each of said rules associated with each gateway node In said gateway-zone 
10 graph that is encountered between said at least one source address and said at least one destination 

address. 

20. The tool of claim 1 9, wherein said rules are expressed as rule-base objects 

15 21 . The tool of claim 19, wherein said gateway-zone graph is derived from a network topology file. 

22. The tool of claim 19. wherein said query includes a wildcard for at least one of said service, source address or 
destination address. 

£0 23. The tool of claim 1 9, further comprising the step of detemiining a portion of said one or more given services that 
are permitted between at least one source address and at least one destination address. 

24. The tool of claim 1 9, farther comprising the step of transfomiing said packet filtering configuration files Into a table 
of logical rules that are processed during said evaluating step. 

25 

25. The tool of claim 19. wherein said query consists of a source host-group, a destination host-group, and a sewice 
host-group. 

26. The tool of claim 1 9, wherein said query spectfies a location where packets are to be inserted into the network that 
30 is different from a source address. 

27. A computer readable medium having computer readable program code means embodied thereon, said computer 
readable program code means analyzing at least one gateway in a network, said at least one gateway having a 
packet filtering configuration file including a plurality of rules, saki network having a plurality of addresses, said 

35 computer readable program code means comprising: 

a step to generate a gateway-zone graph that models said network, said gateway-zone graph having at least 
one gateway node corresponding to said at least one gateway and at least two zone nodes, wherein said at 
least one gateway is a packet filtering machine and each of said zone nodes correspond to a partitioned 
40 collection of said addresses created by said at least one gateway; 

a step to receive a query inquiring whether one or more given sen^ices are pemnitted between at least one 
source address and at least one destination address; and 

45 a step to evaluate said query against each of said rules associated with each gateway node in said gateway- 

zone graph that is encountered between said at least one source address and said at least one destination 
address. 

28. A system for modeling a network, comprising: 

50 

a memory for storing computer readable code; and 

a processor operatively coupled to said memory, said processor configured to: 

55 identify each gateway devtee in said networic having a packet-filtering rule-base and each zone in said 

network defined by said gateway devices; and 

generate a gateway-zone graph that models said networtc. said gateway-zone graph having a gateway 
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node corresponding to each of said gateway devices and a zone node corresponding to each of said zones. 

29. A computer readable medium having computer readable program code means embodied thereon, said computer 
readable program code means comprising: . 

5 

a step to identify each gateway device in a networl< having a packet-filtering rule-base and each zone In said 
network defined by said gateway devices; and 

a step to generate a gateway-zone graph that models said network, said gateway-zone graph having a gateway 
node corresponding to each of said gateway devices and a zone node corresponding to each of said zones. 



15 



20 



23 



30 



35 



40 



45 



SO 



55 



17 



BNSDOCID: <EP 11 19151 A2J.> 



EP 1 119151 A2 




owcnnrjirv -'PP 



11igi51A2 i > 



18 



EP1 119 151 A2 



'OLOGY 
HLE 








si 









&3 

52 











ii 














or ^ 














i 


a/ 

csl 





J — ? 



CXI 



1 



CM 


CD § 




o 

^ S2 




!±f § C 


• • • ' 




FI 


^1 







I 



19 

BNSDOaO: <EP 1 1 tOtSI A2J.> 




20 



EP1 119151 A2 



FIG. 4 
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FIG. 5 
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alyzing the operation of one or more network gateways, 
such as firewalls or routers, that perfonn a packet filter- 
ing function in a network environment. Given a user que- 
ry, the disclosed firewall analysis tool simulates the be- 
havior of the varbus firewalls, taking into account the 
topology of the network environment, and determines 
which portions of the services or machines specified in 
the original query would manage to reach from the 
source to the destination. The relevant packet-filtering 
configuration files are collected and an internal repre- 
sentation of the implied security policy is derived. A 
graph data structure is used to represerit the network 



topology. A gateway-zone graph pemnits the firewall 
analysis tool to determine where given packets will trav- 
el in the network, and which gateways will be encoun- 
tered along those paths. In this manner, the firewall anal- 
ysis tool can evaluate a query object against each rule- 
base object, for each gateway node in the gateway-zone 
graph that is encountered along each path between the 
source and destination. A graphical user interface is pro- 
vided for receiving queries, such as whether one or 
more given services are pemnltted between one or moire 
given machines, and providing results. A spoofing at- 
tack can be simulated by altowihg the user to specify 
where packets are to be injected into the network, whrch 
may not be the true location of the source host-group. 
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